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ABSTRACT 


We  explore  two  methods  for  real-time  generation  of  more  realistic  two  and  three- 
dimensional  terrain  displays  than  what  are  currently  available  on  relatively 
inexpensive  graphics  workstations.  The  first  method  involves  using  a  high-resolution 
terrain  elevation  database.  The  second  method  involves  coloring  and  shading  the 
terrain  with  gray-scale  data  obtained  from  associated  aerial  photography.  Both 
methods  were  implemented  with  a  three-dimensional  simulator .  utilizing  a  high- 
resolution  digital  terrain  database  that  was  generated  from  processed  F-14  stereo 
imagery.  We  describe  our  simulator,  the  High-Resolution  Digital  Terrain  Model 
(HRDTM),  listing  its  capabilities  and  graphics  features.  We  also  present  how  the 
system  performs  on  a  high-performance  graphics  workstation. 

The  High-Resolution  Digital  Terrain  Model  simulator  was  developed  as  part  of  a 
joint  master  of  science  degree  thesis  for  Captain  William  O.  Breden,  USMC  and 
Captain  James  J.  Zanoli,  USA.  Captain  Breden  was  responsible  for  database 
manipulation,  the  user  interface,  the  two  and  three-dimensional  terrain  display,  the 
magnification  capability,  the  variable  gamma  ramp  capability;  and  the  camera  (laser 
printing)  capability.  Captain  Zanoli  was  responsible  for  file  input/output, •  elevation 
contour  map  and  aerial  photo  display,  initial  three-dimensional  terrain  display,  and 
data  panel  performance  measurements. 
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I.  SIMULATOR  DEVELOPMENT  AND  PERFORMANCE  HISTORY 


A.  INTRODUCTION 

The  development  of  high-performance  graphics  workstations  and  digital  terrain 
elevation  databases  has  led  to  the  production  of  some  very  good,  and  yet  relatively 
inexpensive,  flight  and  moving  platform  simulators  [Ref.  1,2].  The  problem  with  these 
simulators,  however,  is  the  tradeoff  that  exists  between  realism  and  performance; 
essentially,  the  more  realistic  the  simulation,  the  slower  the  simulator.  In  order  to 
increase  speed  or  performance,  realism  must  be  slighted. 

Using  the  United  States  Naval  Postgraduate  School’s  Moving  Platform  Simulator 
(MPS)  [Ref.  2]  as  our  paradigm,  we  focus  on  current  simulator  capabilities  and 
performance.  We  then  seek  to  improve  the  realism  of  the  graphical  terrain  display 
without  significantly  degrading  system  performance.  In  order  to  better  understand  the 
Moving  Platform  Simulator  and  the  improvements  we  seek,  we  first  review  the 
system  and  how  it  has  evolved. 

B.  FOGM  MISSILE  SIMULATOR 

The  Fiber-Optically  Guided  Missile  (FOGM)  simulator  [Ref.  3]  was  the  first  in  a 
series  of  simulators  developed  at  the  Naval  Postgraduate  School  that  led  to  the 
design  of  MPS.  The  FOGM  was  implemented  in  June  1987  on  a  Silicon  Graphics,  Inc. 
IRIS  3120  graphics  workstation.  The  s.mulator  presented  a  three-dimensional  view 
from  the  missile  as  it  flew  over  a  10  kilometer  x  10  kilometer  area  of  Fort  Hunter- 
Liggett.  California.  In  addition  to  the  terrain,  the  simulator  is  also  capable  of 
displaying  vehicles  that  are  assigned  initial  headings  and  speed.  Since  the  IRIS  3120 
does  not  have  the  hardware  to  support  real-time,  double-buffered,  hidden  surface 
elimination,  all  drawing  was  accomplished  using  a  scauiine  Painter’s  algorithm.  All 
polygons  are  sorted  from  farthest  away  to  closest  to  the  viewer’s  position  and  then 


drawn  in  that  order  to  ensure  that  objects  closer  to  the  viewer  are  not  obscured  by 
distant  objects.  Vehicles  are  drawn  after  the  terrain  is  displayed  |Ref.  2:p.  4). 

C.  VEH  VEHICLE  SIMULATOR 

The  vehicle  (VEH)  simulator  [Ref.  4j,  also  implemented  on  a  Silicon  Graphics, 
Inc.  IRIS  3120  graphics  workstation,  is  an  extension  of  the  FOGM  simulator.  The 
VEH  simulator,  completed  in  December  1987,  contains  the  same  features  for  drawing 
terrain  and  vehicles  as  the  FOGM  with  the  exception  that  only  terrain  in  the  field-of- 
view  is  drawn  using  the  scanline  Painter’s  algorithm.  Additionally,  the  VEH 
simulator  allows  for  real-time  selection  and  control  of  ground  vehicles  [Ref.  2:  p.  5|. 

D.  FOGM/VEH  NETWORKING  SIMULATOR 

The  FOGM/VEH  NET  allows  networking  between  the  FOGM  and  VEH 
simulators.  This  networking  is  accomplished  over  the  Ethernet  local  area  network 
that  ties  the  graphics  workstations  together.  The  networking  permits  simultaneous 
vehicle  position  updating  on  the  FOGM  workstation  while  the  user  of  the  VEH 
operates  a  vehicle  from  his  workstation.  Networking  also  allows  the  missile  flown  on 
one  workstation  to  be  seen  on  the  second  workstation  [Ref.  2:p.  5]. 

E.  VEH  II  VEHICLE  SIMULATOR 

The  VEH  II  simulator,  completed  in  June  1988,  was  the  result  of  not  only  software 
enhancements  to  the  VEH  but  also  porting  the  VEH  from  the  IRIS  3120  to  an  IRIS 
4D/70G  and  an  IRIS  4D/70GT,  VEH  II  has  all  the  capabilities  of  the  VEH  simulator, 
but  modifications  allow  the  simulator  to  run  on  the  newer  hardware  and  under  the 
MEX  [Ref.  5[  and  4Sight  [Ref.  6]  window  management  systems.  Additionally,  VEH 
II  provides  popup  menus  for  all  user  selected  options,  the  ability  to  add  vehicles  to 
the  simulator  at  any  lime,  and  an  option  to  save  convoy  status  to  a  file  that  can  be 
entered  into  the  simulator  w;*h  the  appropriate  popup  menu  selection  [Ref.  2:p.  5]. 


F.  MOVING  PLATFORM  SIMULATOR 


The  Moving  Platform  Simulator  (MPS),  completed  in  December  1988,  is  a 
combination  of  the  FOGM  and  VEH  II  simulators.  MPS  was  designed  on  and  takes 
advantage  of  many  features  built  into  the  hardware  of  an  IRIS  4D/70GT  graphics 
workstation.  MPS  allows  the  user  to  select  a  10  kilometer  x  iO  kilometer  grid  area 
from  a  35  kilometer  x  35  kilometer  database.  The  terrain  color  scheme  is  variable,  and 
an  efficient  terrain  drawing  algorithm  is  able  to  display  more  terrain  than  earlier 
models  by  including  distance  attenuation.  Z-buffering  is  used  for  hidden  surface 
elimination.  A  selectable  month  and  hour  option  determines  the  sun’s  location  and 
sets  the  parameters  for  realistically  lighted  vehicles  and  terrain.  The  system  also 
provides  the  FOGM  missile  the  ability  to  track,  target,  and  destroy  vehicles.  A 
collision  detection  scheme  ensures  that  wrecked  vehicles  are  rendered  inoperative. 
Broadcast  networking  permits  multiple  simulations  to  run  on  different  IRIS  4D/70GT 
graphics  workstations  [Ref.  2:p.  8], 

G.  TERRAIN  DATABASE 

The  terrain  database  that  all  the  simulators  use  was  provided  to  the  Naval 
Postgraduate  School  by  the  United  States  Army  Combat  Developments 
Experimentation  Center  (CDEC)  at  Fort  Ord,  California.  The  database  is  a  special 
Defense  Mapping  Agency  (DMA)  database  that  consists  of  elevation  and  vegetation 
data  in  12.5  meter  increments  in  the  36  kilometer  x  35  kilometer  area  encompassing 
Fort  Hunter- Liggett,  California.  Each  data  point  contains  16  bits.  The  three  most 
significant  bits  are  a  vegetation  code,  which  is  ignored  by  the  simulators,  and  the 
remaining  13  bits  represent  the  elevation  of  the  point  measured  in  feet.  The  Moving 
Platform  Simulator  uses  a  35  kilometer  x  35  kilometer  area  with  a  resolution  of  100 
meters.  This  subset  of  the  original  database  consists  of  245,000  bytes;  100  samples 
per  square  kilometer,  1225  (35  x  35)  square  kilometers,  and  two  bytes  per  sample 
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yield  245,000  (100  x  1225  x  2)  bytes.  At  the  time  of  this  writing,  MPS  has  just  been 
modified  to  display  the  12.5  meter  resolution  data  [Ref.  2:pp.  9-101. 

H.  PERFORMANCE  HISTORY 

!.  FOGM,  VEH,  VEH  II  Measured  Performance 

As  the  VEH  II  evolved  from  the  FOGM,  performance  improved  dramatically. 
The  increased  performance  was  a  direct  result  of  improved  hardware.  Performance 
measurements  of  the  three  simulators  are  based  upon  the  number  of  frames  drawn 
per  second.  As  the  simulators  were  ported  from  the  IRIS  3120  to  the  IRIS  4D/70G. 
performance  doubled.  Performance  doubled  again  after  porting  the  simulators  to  the 
IRIS  4D/70GT.  On  the  relatively  slow  IRIS  3120  workstation,  the  simulators  would 
run  at  six  to  eight  frames  per  second.  Performance  was  measured  at  seven  to  14 
frames  per  second  on  the  IRIS  4D/70G  and  16  to  30  frames  per  second  on  the  IRIS 
4D/70GT.  Typical  measurements  obtained  from  VEH  and  VEH  II  simulations  running 
on  an  IRIS  3120,  an  IRIS  4D/70G,  and  an  IRIS  4D/70GT  are  shown  in  Tables  1.1,  1.2, 
and  1.3  [Ref.  2:pp.  6-7]. 

2.  MPS  Measured  Performance 

Since  MPS  is  much  more  complex  than  any  of  its  predecessors,  it  is  very 
difficult  to  compare  it  to  them.  However,  a  few  measurements  do  offer  excellent 
performance  measurement  benchmarks  that  can  be  used  to  compare  MPS  to  other 
systems,  past  and  present.  The  number  of  polygons  drawn  per  frame  and  the  number 
of  frames  drawn  per  second  are  two  such  measurements.  Typical  measurements 
obtained  from  MPS  running  on  an  IRIS  4D/70GT  are  shown  in  Table  1.4  [Ref.  2:pp. 
61-63]. 

3.  Simulator  Realism 

The  goal  of  the  work  at  the  Naval  Postgraduate  School’s  Graphics  and  Video 
Laboratory  is  to  develop  accurate  real-time  three-dimensional  graphics  simulations 


TABLE  1.1  ONE  VEHICLE  ON  TERRAIN  (FRAMES  /  SECOND) 


SIMULATOR  /  MACHINE 

15  DEGREE  VIEW 

55  DEGREE  VIEW 

VEH/ IRIS  3120 

8.0 

6.5 

VEH  II  /  IRIS  4D/70G 

14.0 

7.0 

VEu  II  /  IRIS  4D/70GT 

30.0 

16.0 

TABLE  1.2  NINE  VEHICLES  IN  VIEW  ON  TERRAIN 
(FRAMES  /  SECOND) 


SIMULATOR  /  MACHINE 

VEH /IRIS  3120 

VEH  II  /  IRIS  4D/70G 

VEH  II  /  IRIS  4D/70GT 

15  DEGREE  VIEW 

4.0 

5.0 

10.0 

55  DEGREE  VIEW 

3.5 

3.0 

6.0 

TABLE  1.3  NINE  VEHICLES  ON  TERRAIN, 

(FRAMES  /  SECOND) 

NONE  IN  VIEW 

SIMULATOR  /  MACHINE 

15  DEGREE  VIEW 

55  DEGREE  VIEW 

VEH /IRIS  3120 

6.0 

5.0 

VEH  II  /  IRIS  4D/70G 

12.0 

7.0 

VEH  II  /  IRIS  4D/70GT 

25.0 

16.0 
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TABLE  1.4  MPS  PERFORMANCE  MEASUREMENTS  ON  IRIS  4D/70GT 


DISPLAYING  DETAILED  TERRAIN 

ZOOM  POLYGONS 

PER 

FRAMES 

PER 

PLATFORM 

ANGLE 

FRAME 

SECOND 

ONE  VEHICLE 

55 

763 

8 

ONE  VEHICLE 

15 

403 

14 

NINE  VEHICLES 

55 

1086 

6 

NINE  VEHICLES 

15 

722 

8 

MISSILE  1500m 

90 

19801 

<  1 

MISSILE  1500m 

10 

3387 

2 

DISPLAYING  ATTENUATED  TERRAIN 

ZOOM  POLYGONS 

PER 

FRAMES 

PER 

PLATFORM 

ANGLE 

FRAME 

SECOND 

ONE  VEHICLE 

55 

607 

9 

ONE  VEHICLE 

15 

393 

15 

NINE  VEHICLES 

55 

940 

7 

NINE  VEHICLES 

15 

680 

9 

MISSILE  1500m 

90 

4152 

2 

MISSILE  1500m 

10 

816 

7 
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on  commercially  available  graphics  hardware.  The  hardware  must  be  powerful  enough 
to  handle  the  demands  of  a  real-time  system,  but  it  must  be  relatively  inexpensive. 
The  $100,000  price  range  is  considered  inexpensive  for  our  purposes.  The  graphics 
displays  should  provide  as  much  detail  as  possible  while  still  allowing  a  two  to  three 
frame  per  second  update.  The  simulators  developed  to  date  all  meet  the  two  to  three 
frame  per  second  update  requirement;  however,  detail  is  lacking  in  all  the  graphics 
displays.  Figures  1.1  and  1.2  depict  examples  of  current  displays  that  are  achieveable 
on  the  Moving  Platform  Simulator  using  a  100  meter  resolution  terrain  elevation 
database.  Recent  improvements  to  MPS  permit  12.5  meter  resolution  displays  that 
offer  quite  a  bit  more  realism  than  the  100  meter  resolution  displays.  Figures  1.3  and 
1.4  depict  these  recently  obtained  results.  These  simulators,  however,  fail  to  display 
cultural  features  and  vegetation.  It  is  this  lack  of  information  that  inspired  us  to  use  a 
higher  resolution  terrain  elevation  database  colored  and  shaded  with  its 
corresponding  aerial  photo  gray-scale  in  our  quest  for  a  realistic  real-time  simulator. 
Our  ultimate  objective  is  to  obtain  image  quality  and  detail  similar  to  that  of  the  black 
and  white  photos  of  Fort  Hunter-Liggett  depicted  in  Figures  1.5  and  1.6  [Ref.  l:p.  2]. 
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Figure  l.l  Moving  Platform  Simulator  100  Meter  Uesolutiou  Display 


I  iguie  1.2  Mo\iug  Platform  Simulator  100  Meier  Resolution  Display 


II.  HIGH-RESOLUTION  DIGITAL  TERRAIN  MODEL  DESCRIPTION 

A.  SYSTEM  OVERVIEW 

The  High-Resolution  Digital  Terrain  Model  (HRDTM)  simulator  is  a  real-time 
moving  platform  simulator  that  models  the  nap-of-the-earth  flight  of  a  fiber-optically 
guided  missile  over  three-dimensional  terrain.  The  HRDTM  simulator  allows,  to  a 
limited  extent,  cultural  feature  and  vegetation  displays  through  textured  terrain, 
terrain  that  is  colored  and  shaded  with  its  corresponding  aerial  photo  reflectance 
(gray-scale)  data.  HRDTM  research  employs  software  methodology  that  seeks  to 
improve  the  accuracy  and  realism  of  the  images  generated  by  the  Moving  Platform 
Simulator  [Ref.  2]  while  maintaining  real-time  system  performance.  HRDTM  was 
developed  separately  from  the  Moving  Platform  Simulator;  but,  it  was  intended  for 
integration  with  MPS. 

B.  PROGRAMMING  TOOLS  AND  ENVIRONMENT 

HRDTM  is  designed  and  implemented  on  a  Silicon  Graphics,  Inc.  IRIS  4D/70GT 
graphics  workstation.  The  workstation’s  programming  environment  is  based  on  the 
AT&T  Unix  System  V  operating  system  and  the  4Sight  window  management  system. 
The  environment  includes  an  optimized  C  language  compiler  and  a  complete  graphics 
library  that  provides  routines  for  fast  polygon  fill,  hidden  surface  elimination,  and  fast 
pixel  access  [Ref.  5,  6,  7]. 

C.  SYSTEM  FEATURES 

The  HRDTM  simulator  takes  advantage  of  the  fact  that  multiple  window 
operations  can  run  concurrently  under  the  4Sight  Window  Manager.  HRDTM  runs  six 
windows  concurrently.  Figure  2.1  depicts  the  system’s  window  layout.  Three 
windows,  however,  provide  nothing  more  than  title  information  for  the  other  three 
windows  located  beneath  them.  Of  the  three  windows  that  display  the  bulk  of  the 
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1.  Main  Window  4.  Magnify  Window 

2.  Main  Title  Window  5.  Contour  Map  Title  Window 

3.  Magnify  Title  Window  6.  Contour  Map  Window 


Figure  2.1  System  Window  Layout 

simulator’s  graphics,  the  main  window  is  perhaps  the  most  important.  The  main 
window  allows  for  the  static  two-dimensional  gray-scale  aerial  photo  display  or  the 
dynamic  three-dimensional  missile  view  display  of  a  selected  area  of  terrain.  The 
terrain  selection  is  made  from  a  second  window,  the  contour  map  window,  which 
displays  either  the  gray-scale  aerial  photo  or  the  elevation  contour  map  of  the  entire 
terrain  database.  The  final  window,  the  magnify  window,  was  designed  primarily  to 
display  a  magnified  view  of  the  terrain  displayed  under  the  cursor  in  the  main  window. 
Robustness  in  the  code,  however,  permits  the  window  to  display  the  magnified 
version  of  any  object  located  under  the  cursor  positioned  anywhere  on  the  screen. 
Additionally,  the  window  can  be  set  to  display  the  contour  map’s  elevation  legend,  or 
it  can  be  set  to  display  a  data  panel  that  depicts  the  simulator’s  three-dimensional 
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drawing  performance  and  missile’s  technical  data  such  as  speed,  height,  course,  and 
view  angle. 

The  HRDTM  simulator  is  extremely  simple  to  use.  The  entire  simulation  is  driven 
by  a  popup  menu  that  provides  roll-off-the-side  menu  options.  Besides  the  main 
menu  options,  the  user  can  control  missile  parameters  with  the  IRIS  dial  box  while 
the  simulator  is  in  the  three-dimensional  terrain  display  mode.  The  data  panel  display 
permits  the  user  to  view  a  legend  of  the  dial  box  and  current  missile  parameters.  A 
detailed  description  of  system  execution,  to  include  a  description  of  the  user  interface, 
is  presented  in  Chapter  4. 
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III.  OPERATING  AREA 


A.  DATABASE  PROCESSING 

The  high-resolution  digital  terrain  database  used  in  the  HRDTM  simulator  was 
produced  by  GeoSpectra  Corporation  in  Ann  Arbor,  Michigan.  The  database  was 
obtained  by  processing  F-14  stereo  photography  of  Fort  Hunter-Liggett,  California. 
The  F-14  carried  the  KS-87B  framing  camera  that  has  a  six  inch  focal  length. 
Approximately  80  square  kilometers  of  the  Fort  Hunter-Liggett  area  were 
photographed  between  0900  and  1100  a.m.  (Pacific  Standard  Time),  23  June  1987, 
from  an  altitude  of  6,000  feet.  A  small  sample  of  this  photo  coverage,  approximately 
one  square  kilometer,  was  selected  and  processed  into  the  HRDTM  simulator’s 

digital  database  using  GeoSpectra’s  ATOM®  software  [Ref.  8]. 

ATOM  (Automatic  TOpographic  Mapper)  [Ref.  9:p.  1[  is  a  modularized 
photogrammetric  program  developed  for  a  VAX  mini-computer.  It  is  designed  to 
correlate  eight  bit  digitized  stereo  photography  and  measure  parallax  for  each  image 
pixel.  The  digitized  photography  that  the  program  analyzes  is  obtained  by  scanning 
stereo  photos  with  an  Optronics  Scanner,  and  a  Raster  Technologies  interactive 
display  is  used  to  locate  and  identify  more  than  five  image  match  points  with  known 

(R) 

elevations.  ATOM  consists  of  six  functional  modules  [Ref.  10). 

Module  one,  the  control  module,  requires  manual  input  of  the  camera’s  focal  length 
and  altitude,  (or  the  photo  scale),  a  minimum  and  maximum  elevation,  and  more  than 
five  control  points.  This  module  presents  an  interactive  display  that  permits  the 
operator  to  roam  through  stereo  pairs  on  a  split  screen.  The  control  module  performs 
the  necessary  computations  to  orient  one  photo  of  the  stereo  pair  with  respect  to  the 
other.  At  the  end  of  this  module,  the  operator  is  able  to  review  the  accuracy  of  the 
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stereo  model’s  residual  Y  parallax  and  delta  Z  on  point  reference  elevations.  This 
module  normally  requires  about  an  hour  of  the  operator’s  time  [Ref.  10J. 

Module  two,  the  resample  module,  resamples  the  left  and  right  images  into 
epipolar  space.  This  is  a  batch  processing  module  that  runs  two  to  three  hours  on  a 
VAX  11/750,  given  81  megabyte  images  [Ref.  10]. 

Module  three,  the  elevmap  module,  is  a  batch  processing  module  designed  to 
correlate  pixels  with  eight  bits  of  brightness.  The  speed  of  this  module  is  variable  and 
is  a  function  of  the  parallax  range  [Ref.  10]. 

Module  four,  the  editor  module,  allows  the  operator  to  interactively  compare  the 
stereo  image  data  and  elevation  data.  This  module  is  used  to  interpolate  correlation 
errors  not  caught  by  automatic  editors  [Ref.  10]. 

Module  five,  the  ortho  module,  is  a  batch  processing  module  that  adjusts  the  X 
and  Y  location  of  each  image  pixel  with  respect  to  its  elevation  [Ref.  10]. 

Module  six,  the  utilities  module,  includes  routines  that  correct  for  lens  and 
atmospheric  distortions  as  well  as  the  earth’s  curvature.  This  module  was  developed 
for  processing  small  scale  photos  taken  from  the  space  shuttle  [Ref.  10]. 

(K) 

The  output  of  ATOM  consists  of  two  digital  data  files,  an  elevation  file  and  a 
reflectance  file.  The  first  file  consists  of  a  very  high  density  raster  of  terrain  elevation 
data,  and  the  second  file  consists  of  a  co-registered  raster  of  image  brightness  (gray¬ 
scale)  data.  The  elevation  file  represents  point  elevations  of  each  image  pixel,  either 
of  bare  ground,  vegetation,  or  other  features  on  the  ground  [Ref.  10]. 

B.  FORT  HUNTER-LIGGETT  DATABASE 

The  terrain  database  that  the  High-Resolution  Digital  Terrain  Model  uses  is  a 
modified  version  of  the  GeoSpectra-produced  database  that  was  provided  to  the 
Naval  Postgraduate  School  by  the  United  States  Army  Combat  Developments 
Experimentation  Center  (CDEC)  at  Fort  Ord,  California.  The  database  consists  of 
two  files,  an  elevation  data  file  and  a  corresponding  aerial  photo  reflectance  (gray- 


scale)  data  file.  The  elevation  file  provides  0.1  meter  elevation  accuracy  for  data 
points  that  were  sampled  every  0.3  meters  on  the  ground.  The  reflectance  file 
provides  the  corresponding  gray-scale  data.  Data  points  are  sampled,  in  0.3  meter 
increments,  from  the  area  formed  by  a  square  with  the  upper  left  comer  at  the 
geodesic  coordinate  N3972300,  E667900  and  the  lower  right  comer  at  N3971000, 
E669200.  These  vertices  were  required  in  order  to  fit  the  entire  sample  data  set  into 
the  coordinate  system.  Figure  3.1  depicts  a  graphical  layout  of  the  database  while 
Figure  3.2  depicts  the  actual  area  of  terrain  on  a  1:24,000  scale  map  produced  from 
map  sheets  DMA  1755  I  NW  and  AMS  1755  I  SW  -  Series  V895,  dated  1949  and 
photoinspected  in  1976.  Data  records  are  stored  west  to  east,  and  successive  records 
are  stored  north  to  south.  The  area  is  1.3  kilometers  wide  and  1.3  kilometers  high. 
Each  elevation  sample  consists  of  16  bits  (two  bytes)  which  when  converted  to 
decimal  represents  the  elevation  in  tenths  of  meters.  The  decimal  number  4953,  for 
instance,  would  represent  495.3  meters.  Each  reflectance  sample  also  consists  of  16 
bits  (two  bytes)  and  when  converted  to  decimal  represents  the  aerial  photo’s  gray¬ 
scale  level,  an  integer  value  between  0  (black)  and  255  (white). 

C.  MODIFIED  FORT  HUNTER-LIGGETT  DATABASE 

The  original  database  described  above  was  modified  to  permit  faster  indexing  into 
the  array  of  terrain  data  and  to  eliminate  unnecessay  data  which  was  consuming  a 
huge  amount  of  disk  storage  space.  The  first  modification  eliminated  the  zeros  that 
were  used  to  "pad"  or  "fill  in"  the  square  that  surrounds  the  rectangular  'f 

interest.  The  second  modification  reorganized  the  data;  essentially,  rotating  the 
rectangular  area  of  data  that  is  shown  in  Figure  3.2  counter-clockwise  until  the 
resulting  database  shown  in  Figure  3.3  was  achieved.  Converting  the  two  byte 
reflectance  data  file  to  a  one  byte  data  file  constitutes  the  third  modification.  Inserting 
header  information  of  six  bytes  representing  the  file  type,  row  size,  and  column  size  of 
each  file  comprises  the  fourth  and  final  modification.  As  a  result  of  these 


Figure  3.1  Original  Database  Layout 
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Figure  3.3  Modified  Database  Layout 

modifications,  the  database  is  much  more  compact  and  easier  to  access.  The  modified 
elevation  data  file  contains  12,819,210  (4001  rows  of  data  x  1602  columns  of  data  x  2 
bytes  per  data  sample  +  6  bytes  per  header)  bytes  of  data.  The  modified  reflectance 
data  file  contains  6,409,608  (4001  rows  of  data  x  1602  columns  of  data  x  1  byte  per 
data  sample  +  6  bytes  per  header)  bytes  of  data.  Thus,  19,228,818  bytes  of  disk 
space  are  required  for  storing  the  entire  terrain  database. 

D.  SELECTION  METHODOLOGY 

The  HRDTM  simulator  is  designed  to  allow  the  user  to  select  any  960  sample  x 
960  sample  (288  meter  x  288  meter)  area  from  the  entire  database.  The  user  is  not 
restricted  to  selecting  an  area  that  begins  and  ends  o n  a  one  kilometer  grid  line  as  is 
the  case  in  the  Moving  Platform  Simulator.  The  960  x  960  restriction  is  due  to  the 
main  window  size  which  is  960  pixels  x  960  pixels  and  the  manner  in  which  the  two- 
dimensional  aerial  photo  is  displayed  using  a  system  call  that  displays  data  samples 
using  a  fast  pixel  fill  method. 
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E.  COLOR  SCHEME 

The  HRDTM  simulator  uses  only  one  color  scheme.  All  terrain,  whether  two- 
dimensional  or  three-dimensional,  is  colored  and  Gouraud  shaded  with  its 
corresponding  aerial  photo  reflectance  data. 

The  elevation  contour  map  can  however  be  displayed  using  two  different  ramps,  a 
gray  ramp  or  a  brown  ramp.  Both  ramps  consist  of  16  shades  of  either  gray  or  brown; 
the  darker  the  shade,  the  higher  the  elevation.  The  16  intervals  are  evenly  spaced 
between  the  lowest  and  highest  elevations  in  the  database.  The  lowest  and  highest 
elevations  are  defined  as  constants  in  the  program.  They  were  obtained  by  running  a 
separate  search  program  on  the  elevation  data  file.  This  information  can  be  added  as 
part  of  the  elevation  data  file  header;  thus,  eliminating  the  need  for  constants  and 
permitting  the  use  of  additional  data  files. 
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IV.  GRAPHICS  DISPLAY  SPECIFICS 


A.  SUPPORTING  GRAPHICS  HARDWARE/SOFTWARE 

1.  IRIS  Display  Memory 

The  display  memory  on  the  IRIS-4D/70  GT  is  organized  as  a  set  of  96 
bitplanes.  A  bitplane  contains  one  bit  of  information  for  each  pixel  on  the  screen; 
therefore,  up  to  96  bits  of  information  can  be  savtd  for  each  pixel  on  the  screen.  The 
screen  is  1,280  bits  wide  and  1,024  bits  high,  which  implies  that  each  bitplane  holds 
1,310,720  (1,280  x  1,024)  bits  of  information.  These  bits  store  color  information  as 
well  as  information  about  depth,  overlays  and  underlays,  and  an  alpha  channel  [Ref.  7: 
P-  4-1]. 

2.  Color/Multimap  Modes 

The  IRIS  graphics  workstation  provides  RGB  and  color  map  modes.  RGB 
mode  permits  the  programmer  to  dynamically  create  colors  by  setting  the  red,  green, 
and  blue  color  gun  intensities  of  desired  pixels  [Ref.  7:p.  4-2].  Color  map  mode,  on 
the  other  hand,  requires  the  user  to  predefine  colors  that  are  later  indexed  from  a 
table  of  4096  possible  entries  [Ref.  7:  p.  4-13].  Multimap  mode  divides  the  system’s 
color  map  table  of  4096  entries  into  16  maps  of  256  entries  [Ref.  7:  p.  4-21], 

3.  Double  Buffering 

Double  buffering  is  a  technique  used  for  smoothing  motion  between  images 
that  change  with  time.  This  capability  is  achieved  by  hardware  in  the  IRIS  graphics 
workstation.  The  system’s  standard  bitplanes  are  divided  into  two  halves;  one  half 
is  displayed  (visible  buffer),  while  drawing  is  performed  in  the  other  half  (invisible 
buffer).  The  buffers  are  swapped  when  the  drawing  is  complete,  and  the  previously 
invisible  buffer  (the  next  frame)  becomes  visible,  and  the  previously  visible  buffer 
becomes  invisible  and  available  for  drawing  the  following  frame  [Ref.  7:  p.  6-1]. 
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4.  Z-Buffering 

The  IRIS  4D/70GT  graphics  workstation  contains  special  hardware  that 
provides  hidden  surface  elimination.  This  hardware  consists  of  a  bank  of  24  bits  (24  z- 
buffer  bitplanes)  that  store  depth  (Z  coordinate)  information.  When  the  IRIS  is  in  z- 
buffer  mode,  the  Z  coordinate  for  each  pixel  is  stored  as  a  24  bit  value  in  the 
bitplanes.  When  a  pixel  is  drawn,  its  new  Z  value,  the  distance  from  the  object  to  the 
viewer’s  eye,  is  compared  to  the  existing  Z  value.  If  the  new  Z  value  is  less  than  or 
equal  to  the  current  Z  value,  the  new  color  and  Z  values  for  that  pixel  are  written  into 
the  bitplanes.  Otherwise,  the  color  and  Z  values  remain  unchanged.  As  a  result,  only 
parts  of  the  image  that  are  actually  visible  to  the  viewer  are  displayed  on  the  screen. 
Note  that  the  values  in  the  z-buffer  always  represent  the  distances  of  the  objects 
closest  to  the  viewer  [Ref.  7:p.  8-3]. 

5.  Gamma  Ramp 

The  IRIS  graphics  workstation  provides  a  gamma  correction  capability,  the 
ability  to  equalize  monitors  with  different  color  characteristics  or  to  modify  the  color 
warmth  of  the  monitor.  The  gamma  factor  actually  represents  the  nonlinearity  of  the 
monitor.  Varying  this  factor  essentially  effects  image  contrast.  The  gammaramp 
function  varies  the  gamma  factor,  effecting  only  the  display  of  color,  not  the  values 
that  are  written  in  the  bitplanes.  It  also  effects  the  entire  screen  and  all  running 
processes.  It  stays  in  effect  until  the  system  hardware  is  reset  or  another  call  to  the 
gammaramp  function  is  made  [Ref.  7:  p.  4-24], 

6.  Overlays 

Information  can  overlay,  be  drawn  over,  the  standard  pixel  contents  of  the 
current  buffer.  The  IRIS  achieves  this  capability  through  its  overlay  bitplanes  that 
supply  additional  bits  of  information  at  each  pixel.  The  significance  of  overlays  is  that 
overlay  bitplanes  can  be  displayed,  modified,  and  then  redisplayed  without  disturbing 
the  current  drawing  [  Ref.  7 :  p.  11-1], 


7.  Gouraud  Shading 

Gouraud  shading  is  a  means  for  varying  the  color  across  a  polygon.  The 
shading  is  achieved,  first,  by  linearly  interpolating  the  colors  of  each  vertex  along  the 
edges  connecting  them.  Then  the  interpolated  colors  along  the  edges  are  interpolated 
again  across  the  interior  of  the  polygon.  Gouraud  shading  can  be  accomplished  in 
RGB  or  Color  Map  mode.  In  RGB  mode,  the  interpolation  is  linear  in  all  three 
components,  the  red,  green,  and,  blue  intensities  [Ref.  7:  p.  4-7].  In  color  map  mode, 
the  color  map  index  is  interpolated  [Ref.  7:  p.  4-15]. 

8.  Fast  Pixel  Access/Display 

The  IRIS  graphics  workstation  supports  high  performance  pixel  access  and 
display.  The  system  function  rectread ,  given  the  lower-left  and  upper-right  corners  of 
a  rectangle,  reads  a  rectangular  array  of  pixels  from  a  window  and  stores  it  in  a  given 
array  ]Ref.  7:p.  1 0-3].  This  array  of  pixels  can  be  displayed  with  the  system  function 
rectwrite  [Ref.  7:p.  10-4],  Note  that  the  system  function  readsource  does  not  work  as 
intended;  it  fails  to  determine  the  source  of  pixels  read  by  rectread.  This  is  a  software 
bug  that  should  be  corrected  in  version  3.2  of  the  IRIS  operating  system.  Additionally, 
rectread  does  not  perform  according  to  specifications.  It  appears  to  read  above  and  to 
the  right  of  the  point  specified  by  the  programmer  [Ref.  7:p.  10-4]. 

B.  MODELING  TECHNIQUES 

1.  FOGM  Parameters 

The  fiber-optically  guided  missile  parameters  include  height,  speed,  tilt  (look- 
down)  angle,  and  course  (heading).  All  parameters  are  user  controlled  and  can  be 
changed  interactively  through  the  IRIS  dial  box.  Height  represents  the  height  of  the 
missile,  in  meters,  above  the  ground.  Missile  height  ranges  from  one  to  400  meters 
above  ground.  The  speed  of  the  missile  is  measured  in  kilometers  per  hour.  Missile 
speed  ranges  between  a  negative  and  positive  four  kilometers  per  hour.  A  negative 


speed  allows  the  missile  to  move  backwards,  while  a  positive  speed  advances  the 
missile.  The  missile  has  a  built-in  45  degree  field-of-view.  This  field-of-view  can  be 
adjusted  to  point  anywhere  between  just  below  the  horizon,  one  degree,  and  directly 
below  the  missile,  89  degrees.  The  course,  or  missile  heading,  is  also  adjustable.  The 
missile  can  rotate  360  degrees.  The  measurements,  made  in  degrees,  are  made 
relative  to  the  missile’s  initial  heading  of  zero  degrees.  The  missile’s  location  and 
field  of  view  are  continually  updated  in  the  contour  map  window  based  upon  the 
missile’s  current  speed  and  heading. 

2.  Timing 

The  HRDTM  simulator  continually  updates  the  missile’s  location  and  drawing 
performance.  In  order  to  update  both  of  these  items,  the  simulator  must  know  the  time 
that  has  elapsed  since  its  last  update.  This  elapsed  time  is  calculated  in  the 
process  time  difference  function  which  queries  the  system  function  times.  This 
system  function  returns  the  current  number  of  clock  cycles  which  is  then  subtracted 
from  the  value  obtained  during  the  previous  program  loop.  This  difference  divided  by 
the  clock  rate  results  in  the  elapsed  time.  Note  that  the  simulator’s  time  function  is 
initialized  in  the  program’s  main  routine.  Figure  4.1  depicts  the  elapsed  time 
calculation.  To  calculate  the  distance  covered  by  the  missile  during  the  elapsed  time, 
the  elapsed  time  is  multiplied  by  the  missile’s  speed;  recall  that  distance  =  rate  x 
time.  We  then  calculate  the  X  and  Z  components  of  total  distance  by  multiplying 
distance  by  the  sine  and  cosine  of  the  missile’s  heading.  The  X  and  Z  components  are 
then  added  to  the  missile’s  current  gridX  and  gridY  components,  thus  updating  the 
missile’s  location.  Figure  4.2  shows  the  code  that  updates  the  missile’s  location 
based  upon  its  current  speed. 

3.  Terrain  Drawing  Algorithm 

The  terrain  drawing  algorithm  is  rather  complicated  since  it  only  draws  terrain 
that  is  in  the  missile’s  field-of-view.  The  algorithm  permits  only  the  terrain  in  the 


/*  This  C  code  was  provided  by  LT.  Gordon  K.  Weeks,  USCG.  */ 

/*  Global  variables  for  time  keeping  */ 

Jong  start_time; 
struct  tms  tirneinfo; 

/*  Process  the  loop  time  difference  */ 

/*  Called  by  updatepositions()  */ 

/*  Calculates  the  time  expended  during  the  last  simulation  loop  and  returns  */ 
/*  the  elapsed  seconds.  */ 

float  process_time_difference() 

{ 

struct  tms  tirneinfo;  /*  System  time  information  */ 
float  elapsedsec;  /*  Returned  time  value  */ 

long  lastsec;  /*  End  time  for  simulation  run  */ 

long  elapsedhz;  /*  Elapsed  machine  cycles  */ 

/*  start_time,  global  start  time  */ 

lastsec  =  times(&timeinfo); 
elapsedhz  =  lastsec  -  start_time; 
elapsedsec  =  (float)(elapsedhz)/(float)HZ; 
start_time  =  lastsec; 

return(elapsedsec); 

} 


Figure  4.1  Process  Time  Calculation 
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/*  This  C  code  represents  a  small  segment  of  the  drawManeuver  */ 

/*  function  that  displays  the  three-dimensional  perspective  view  */ 

/*  Reset  the  variables  used  to  store  the  2  directional  components  of  travel  */ 

delta_x  -=  0; 
delta_y  =  0; 

/*  Distance  =  Rate  x  Time  */ 

/*  Convert  km/hr  to  km/sec  then  scale  the  distance  to  coordinate  system  */ 
/*  Elapsed_time  is  the  number  of  seconds  since  last  missile  update  */ 

distance_covered  =  speed  /  3600.0  *  3333.33  *  elapsed_time; 

/*  Compute  change  in  drawing  position  */ 

/*  Direction  of  travel  is  tied  into  the  viewing  direction  */ 

if  (speed  !=  0) 

( 

delta_x  =  distance_covered  *  cos  (view  *  PI  /  180); 
delta_v  =  distance_covered  *  sin  (view  *  PI  /  1 80); 

} 

/*  Update  the  missile’s  location  by  updating  appropriate  globals  */ 

gridX  =  gridX  +  delta_x; 
gridY  =  gridY  +  deita_.y; 

/*  Display  the  terrain  then  loop  through  the  entire  process  again  */ 

Figure  4.2  Missile  Location  Update 
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missile’s  45  degree  horizontal  and  vertical  fields-of-view  to  be  displayed.  This  is 
done  by  drawing  the  three-dimensional  scene  in  five  degree  arcs,  referred  to  as 
sectors.  As  depicted  in  Figure  4.3,  each  sector  subtends  an  arc  of  five  degrees  with 
the  closed  end  of  the  arc  located  at  the  drawing  point  and  the  open  end  extending  out 
to  the  farthest  points  visible  from  the  viewing  point.  This  method  allows  the 
increase/decrease  in  the  number  of  sectors  drawn  based  on  the  viewing  tilt  angle 
required  to  cover  a  drawing  region  slightly  larger  than  the  viewing  region.  Since  the 
missile  can  achieve  altitudes  to  400  meters,  the  algorithm  must  also  account  for  a 
look-out  as  well  as  a  look-down  capability.  At  the  same  time,  distance  attenuation 
must  be  considered.  Figure  4.4  depicts  the  three-dimensional  terrain  drawing 
algorithm. 


grid  square 
coordinate  system 


Figure  4.3  Sector  Description 


In  HRDTM,  terrain  is  drawn  in  double-buffer  mode  using  the  triangular  mesh 
drawing  routine  provided  by  the  graphics  library.  The  mesh  routine  is  used  in  the  low 
level  drawing  routines  to  draw  square  terrain  segments  as  two  triangles.  The  terrain 
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Three-Dimensional  Terrain  Drawing  Algorithm 

1.  Update  the  missile’s  location  based  upon  its  speed  and  the  elapsed  time 
since  its  last  update. 

2.  Determine  the  elevation  of  the  terrain  immediately  beneath  the  missile. 

3.  Calculate  the  maximum  drawing  distance,  the  furthest  point  from  the  missile 
that  can  be  drawn. 

4.  Adjust  the  drawing  distance  and  the  number  of  sectors  drawn  in  order  to 
reduce  the  drawing  time. 

5.  Ensure  that  the  drawing  distance  does  not  exceed  the  maximum  drawing 
distance  determined  in  step  3. 

6.  Set  the  high-resolution  and  medium  resolution  drawing  distances  to  create  a 
distance  attenuation  effect. 

7.  Set  the  viewing  perspective’s  viewing  angle,  aspect  ratio,  and  clipping 
planes. 

8.  Set  the  lookat  function’s  parameters  to  reflect  current  missile  parameters 
and  information  determined  above. 

9.  Compute  an  offset  point  to  be  used  as  a  drawing  start  point.  Offset  is  used  to 
clear  up  clipping  along  side  of  3D  view. 

10.  Draw  the  3D,  perspective  view  in  sectors. 

1 1.  Update  data  panel. 

12.  Return  to  step  1. 


Figure  4.4  Three-Dimensional  Terrain  Drawing  Algorithm 


27 


is  Gouraud  shaded  by  providing  each  triangular  vertex  its  corresponding  reflectance 
value  and  then  linearly  interpolating  these  values  across  the  edges  and  faces  of  each 
triangle.  The  resulting  view  of  the  terrain  is  a  three-dimensional,  gray-scale,  Gouraud 
shaded  perspective  view  generated  by  the  graphics  library’s  perspective  and  Inokat 
functions.  The  missiles’s  vantage  point  and  viewing  reference  point  are  controlled  or 
modified  by  varying  the  viewer’s  coordinates  and  viewed  target’s  reference  points 
within  the  lookat  function. 

The  missile’s  horizontal  and  vertical  view  angles  are  fixed  at  45  degrees.  The 
distance  from  the  missile  to  the  ground  plane,  along  a  45  degree  angle,  is  calculated 
and  used  to  create  a  pyramidal  viewing  volume.  Figure  4.5  depicts  the  viewing 
volume  with  respect  to  the  elevation  data  array  which  represents  a  partitioned  ground 
plane.  Only  the  terrain  within  this  volume  is  drawn  in  order  to  minimize  the  number  of 
polygons  drawn  and,  thus,  maximize  the  frames  per  second  drawing  update  rate.  By 
varying  the  size  and  position  of  this  viewing  volume,  we  simulate  the  effect  of  moving 
over  three-dimensional  terrain.  Figure  4.6  depicts  the  effects,  on  the  viewing  volume, 
of  varying  the  missile’s  course  or  heading.  Figure  4.7  depicts  the  effects  of  varying 
the  missile’s  height,  and  Figure  4.8  depicts  the  effects  of  varying  the  missile’s  tilt 
angle. 

Additionally,  we  add  to  the  realism  of  the  view  by  simulating  distance 
attenuation,  the  blurring  or  fading  of  distant  terrain.  Objects  close  to  the  viewer  are 
drawn  in  detail,  while  objects  located  further  away  from  the  viewer  are  drawn  in  less 
detail.  We  achieve  this  effect  by  drawing  close  objects  using  every  point  in  the 
database  (high-resolution),  semi-distant  objects  using  every  other  point  in  the 
database  (medium-resolution),  and  distant  objects  using  only  every'  fourth  point  in 
the  database.  At  ground  level,  the  terrain  is  drawn  in  high-resolution  mode  out  to  75 
meters.  Medium-resolution  is  displayed  between  75  and  200  meters,  while  low- 
resolution  is  displayed  between  200  meters  and  the  maximum  distance  drawn,  the 
distance  to  the  farthest  point  in  a  960  x  960  array  of  the  selected  area's  terrain  data. 
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Figure  4.5  Viewing  Volume  Over  Ground  Plane 


Figure  4.6  Simulated  Movement  Through  Viewing 
Volume  Displacement 
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High  Vantage  Point 


Larger  Area  of  Smaller  Area  of 

Displayed  Terrain  Displayed  Terrain 


Figure  4.7  Missile  Height  Variation  Effect 


Figure  4.8  Missile  Tilt  Angle  Variation  Effect 


As  the  viewing  height  and  the  tilt  angle  increase,  the  maximum  drawing  distance 
decreases  causing  less  distant  terrain  to  be  displayed.  Simultaneously,  resolution 
boundaries  are  adjusted  to  account  for  these  changes.  Figure  4.9  depicts  the  distance 
attenuation  drawing  concept,  while  Figure  4.10  depicts  the  boundary  adjustment 
algorithm.  The  boundary  adjustment  algorithm  calls  for  the  boundaries  to  decrease 
one  meter  for  every  three  meter  increase  in  elevation. 

The  maximum  drawing  distance  adjustment  is  based  upon  a  simple  algorithm 
that  is  depicted  in  Figure  4.11.  We  simplify  calculations  by  restricting  the  viewing 
iook-down  angle  to  a  value  between  the  critical  angles  of  22.5  degrees  and  68 
degrees.  This  implies  that  a  45  degree  field-of-view  permits  a  view  between  one  and 
89  degrees  below  the  horizon.  This  restriction  permits  us  to  measure  the  distance 
between  the  missile,  our  vantage  point,  and  the  ground  plane  along  a  45  degree 
azimuth.  With  this  distance,  we  then  solve  for  the  ground  distance  (our  maximum 
drawing  distance)  to  our  target  view  point. 

Since  the  terrain  is  drawn  as  a  series  of  overlapping  five  degree  sectors,  an 
algorithm  also  had  to  be  developed  to  display  a  sufficient  number  of  sectors  to  fill  the 
screen  as  the  viewing  height  and  look-down  angle  increase.  The  viewing  position  first 
had  to  be  adjusted  for  ground  level  because  a  45  degree  field-of-view  drawing  does 
not  fill  the  screen  entirely.  Offsetting  the  viewing  position  forward  of  the  drawing’s 
starting  point  eliminates  the  problem.  Figure  4.3  depicts  this  offset  and  the  resulting 
view.  As  the  tilt  angle  increases,  the  number  of  sectors  drawn  must  also  increase  in 
order  to  fill  the  screen.  A  number  of  trial  runs  enabled  us  to  determine  the  critical 
angles  where  the  number  of  sectors  drawn  did  not  completely  fill  the  screen.  We  use 
these  angles  to  decide  when  we  should  increase  the  number  of  sectors  that  we  draw. 
This  method  simplifies  the  drawing  algorithm  tremendously.  Figure  4.12  depicts  the 
algorithm  that  determines  the  required  number  of  sectors  to  be  drawn  as  the  tilt  angle 
increases. 
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/*  High  and  medium  resolution  drawing  distance  is  based  */ 
/*  on  the  maximum  viewing  distance  and  viewing  height.  */ 
/*  Hi_Res  may  be  displayed  to  75  meters,  and  Med_R.es  */ 
/*  may  be  displayed  to  200  meters.  Distances  greater  than  */ 
/*  200  meters  are  drawn  in  Low_Res.  */ 

Hi_Res  =  (75  -  (viewer_height  /  3))  /  2  *  2; 
if  (Hi_Res  <  0)  Hi_Res  =  0; 

Med_Res  =  (200  -  (viewer_height  /  3))  /  2  *  2; 
if  (Med_Res  <  0)  Med_Res  =  0; 


Figure  4.10  Boundary  Adjustment  Algorithm 

/*  Determine  max  draw  distance  regardless  of  viewing  */ 

/*  direction.  Based  upon  960  x  960  data  array  size.  */ 

if  (gridX  <481)  tmp_x  -  960  -  gridX; 
else  tmp_x  =  gridX; 

if  (gridY  <481)  tmp_y  =  960  -  gridY; 
else  tmp_y  =  gridY; 

Max_Draw_Di  stance  =  sqt  (tmp_x  *  tmp_x  +  tmp_y  *  tmp_y)); 

if  (tilt_angle  <  23)  Draw_Distance  =  Max_Draw_Distance; 
else 

{  Ground_Center_Di stance  =  (((viewer  _height)  *  SCALE)  / 

tan  ((tilt_angie  -  22.5)  *  PI  /  180))); 

if  (tilt_angle  >  45) 

Draw_Distance  =  (Ground_Center_Distance  /  (SCALE  *  2)); 
else 

Draw_Distance  =  Ground_Center_Distance; 


Figure  4.11  Drawing  Distance  Adjustment  Algorithm 
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/*  Terrain  is  drawn  in  a  circular  pattern  consisting  of  5  degree  *1 
/*  sectors.  In  order  to  speed  the  drawing  process,  only  those  */ 

/*  sectors  within  the  field  of  view  are  displayed.  Critical  */ 
/*  angles  were  determined  from  trial  and  error.  Critical  angles  */ 
/*  occurred  when  terrain  would  not  completely  fill  the  screen  */ 
/*  because  an  insufficient  number  of  sectors  were  drawn;  the  */ 
/*  minimum  number  of  sectors  being  6,  calculated  at  ground  */ 
/*  level.  */ 


if  (tilt_angle  <  23)  NumberOfSectors  =  6; 
else 

if  (tilt_angle  >  68)  NumberOfSectors  =  36; 
else  NumberOfSectors  =  (short)  (tilt_angle  /  3.5); 


Figure  4.12  Sector  Calculation 
C.  SIMULATOR  EXECUTION 
1.  System  Start-up 

The  executable  program  file  is  hrdtm.  While  in  the  directory  containing  the 
executable  file,  type  hrdtm  to  start  program  execution.  Six  windows  open  and  run 
concurrently  during  the  HRDTM  simulator  operation. 

After  the  opening  display,  the  contour  map  window  is  cleared  and  an  elevation 
contour  map  of  the  entire  database  is  displayed.  Figure  4.13  depicts  the  elevation 
contour  map  in  the  lower-left  corner  of  the  screen.  The  double-buffered  contour  map 
window  has  the  black  and  white  aerial  photo  of  the  entire  database  drawn  in  the  back 
buffer.  Since  the  elevation  contour  map  and  the  aerial  photo  only  need  to  be  drawn 
once,  we  found  that  double  buffering  enables  us  to  draw  each  in  a  separate  buffer;  a 
menu  option  permits  toggling  between  the  two  buffers  with  no  drawing  time  cost. 
Figure  4.14  depicts  the  aerial  photo  of  the  entire  database.  Note  that  the  photo  and 
contour  map  are  drawn  using  every  third  point  in  the  database.  Since  the  database  is 
so  much  larger  than  the  contour  map  display  window,  displaying  every  point  in  the 
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database  would  cause  much  of  the  data  to  overwrite  or  overdraw  itself.  Thus, 
displaying  every  data  point  only  slows  the  drawing  process;  it  does  not  provide  any 
more  visible  information.  Displaying  anything  less  than  every  third  data  point, 
however,  results  in  unfilled  pixels  and  a  visible  loss  of  information. 

Once  the  elevation  contour  map  and  aerial  photo  are  drawn,  the  contour  map’s 
elevation  legend  is  displayed  in  the  second  of  the  three  primary  windows.  The  legend 
is  depicted  with  the  aerial  photo  in  Figure  4.14.  This  window  is  referred  to  as  the 
magnify  window  in  the  source  code.  The  legend  depicts  the  colors  and  associated 
elevations,  in  meters,  of  the  16  contour  intervals. 

The  user  must  then  select  an  option  from  the  system  menu  in  order  to  continue 
program  execution.  The  system  menu  is  always  invoked  by  depressing  the  right 
mouse  button.  The  system  menu,  a  popup  menu  with  roll-off-the-side  menu  options, 
is  the  primary  source  of  user  input.  The  system  menu  is  depicted  in  Figure  4.15.  Note 
that  the  user  can  select  any  menu  option  at  any  time  during  program  execution. 
However,  if  the  user  chooses  a  menu  option  that  is  not  allowed  or  meaningful  when 
the  menu  is  displayed,  nothing  happens. 

2.  Terrain  Selection 

The  simulator’s  main  window,  the  map  window,  acts  as  a  message  output 
window  as  well  as  a  means  to  display  the  two  and  three-dimensional  views  of 
selected  areas  of  terrain.  As  depicted  in  Figure  4.14,  the  user  is  prompted  to  select 
the  right  mouse  button  for  the  main  menu  once  the  contour  map  and  the  legend  are 
displayed.  The  user  can  then  select  an  area  of  terrain  by  choosing  the  select  area 
menu  option.  After  this  option  is  selected,  a  red  box  appears  in  the  contour  map 
window.  Figure  4.16  depicts  this  selection  box.  The  box  can  be  placed  over  the 
desired  area  by  moving  the  mouse.  Selecting  the  left  mouse  button  loads  that  area’s 
elevation  and  reflectance  data.  Status  messages  printed  to  the  main  window  keep  the 
user  appraised  of  the  system’s  progress.  Once  the  data  is  loaded,  the  user  can 
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display  the  area  in  two  or  three  dimensions  by  making  the  appropriate  menu 
selection.  The  select  area  option  can  be  exercised  any  time  during  simulator  execution. 

3.  Terrain  Display 

Once  the  area  of  terrain  is  selected,  display  the  terrain  by  choosing  either  the 
2D  or  3D  roll-off-the-side  menu  option  to  the  main  menu’s  display  terrain  option. 
The  2D  menu  option  displays,  in  the  main  window,  a  static  two-dimensional  aerial 
photo  of  the  selected  area  of  terrain.  For  the  two-dimensional  display  of  the  selected 
area  of  terrain,  such  as  the  displays  depicted  in  Figures  4.17  and  4.18,  the  simulator 
uses  the  system  function  rectwrite  to  quickly  display  the  array  of  reflectance  values 
which  represent  the  gray-scale  levels  of  the  selected  area  of  terrain.  Note  that 
rectwrite  requires  the  reflectance  data  be  stored  in  row-major  order  in  the  array  to 
avoid  creating  two  similar  images  reduced  in  size. 

The  3D  menu  option  presents  a  nap-of-the-earth  three-dimensional 
perspective  view  of  the  terrain  from  a  fiber-optically  guided  missile.  This  view  is 
changed,  in  real  time,  by  varying  the  missile’s  parameters.  Figures  4.19  and  4.20 
depict  sample  three-dimensional  perspective  views. 

4.  Data  Panel 

Missile  parameters  can  be  observed  in  the  data  panel  that  is  displayed  in  the 
magnify  window  by  selecting  the  data  panel  menu  option.  Figure  4.21  depicts  the  data 
panel.  The  data  panel  not  only  shows  missile  parameters  such  as  height  above 
ground,  course  heading,  speed,  and  tilt  angle  but  also  system  performance  data, 
specifically,  the  number  of  polygons  drawn  in  order  to  create  the  three-dimensional 
view  and  the  rate  that  these  views  are  being  updated  (frames  per  second). 
Additionally,  the  data  panel  provides  a  legend  for  the  dial  box.  The  dial  box,  depicted 
in  Figure  4.22,  provides  the  user  the  means  by  which  he  can  effect  the  missile’s 
parameters.  The  data  panel  is  updated  with  each  frame;  therefore,  the  panel  provides 
current  drawing  data  and  missile  parameters.  The  data  panel  option  can  be  exercised 
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Figure  4.19  Thrcc-1  )imension;il  I’erspeelive  View 
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Figure  4.21  Data  Panel 
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Figure  4.22  IRIS  Dial  l?ov 


any  time  during  simulator  execution.  The  only  time  it  displays  any  useful  information, 
however,  is  when  the  simulator  is  in  the  three-dimensional  terrain  drawing  mode. 

5.  Magnifier 

The  main  menu’s  magnifier  option  provides  a  magnification  or  zoom  capability. 
Selecting  the  magnifier  option  directs  magnified  object  output  to  the  magnify  window 
in  the  upper-left  corner  of  the  screen.  Figures  4.23  and  4.24  depict  examples  of  the 
system’s  magnification  capability.  Any  object  on  the  screen  can  be  magnified.  By 
using  the  mouse  to  place  the  cursor  over  an  object,  the  user  can  view  the  magnified 
object  in  the  magnify  window.  The  magnification  factor  is  displayed  in  the  window’s 
title.  This  factor  can  be  increased,  decreased,  or  reset  to  its  initial  value  by  selecting 
the  appropriate  roll-off-the-side  menu  option  to  the  main  menu’s  magnifier  option. 
Note  that  the  magnification  factor  is  initialized  to  two.  Attempting  to  decrease  this 
factor  has  no  effect.  There  is  no  upper  limit  to  the  magnification  factor;  however,  a 
magnification  factor  greater  than  six  provides  little  additional  information.  Also, 
turning  the  magnifier  off  "freezes”  the  last  magnified  object.  The  magnifier  option  can 
be  exercised  any  time  during  simulator  execution. 

6.  (Jamrna  Ramp  Adjustment 

The  main  menu's  gamma  ramp  option  permits  the  user  to  vary  the  gamma 
correction  factor  of  the  system.  Changing  this  factor  effects  the  color  display  of  the 
entire  screen.  This  is  an  extremely  useful  technique  for  highlighting  or  accenting 
certain  terrain  features.  In  essence,  it  permits  the  identification  of  features  that  would 
not  normally  be  seen.  Figures  4.25  and  4.26  depict  this  capability.  The  gamma  factor 
can  be  increased,  decreased,  or  reset  to  its  initial  value  by  selecting  the  appropriate 
roll-off-the-side  menu  option  to  the  main  menu’s  gamma  ramp  option.  Note  that  the 
gamma  correction  factor  equals  one  when  the  system  begins  execution.  Attempting  to 
increase  this  factor  more  than  ten  times  or  decrease  this  factor  below  its  initial  value 
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I-  i  mi  re  4.25  (iamma  Modific  ation  of  Two-Dimensional  I  drain 


f  i”m  i’  4.26  (iamma  Modification  of  Three-Dimensional  Terrain 


produces  no  visible  effects.  The  gamma  ramp  option  can  be  exercised  any  time  during 
simulator  execution. 

7.  Screen  Dumps  to  Laser  Printer 

The  main  menu’s  camera  option  provides  the  capability  to  print  a  selected 
portion  of  the  screen  on  a  laser  printer.  Selecting  the  camera  option  opens  a  window 
that  is  placed  over  the  left  corner  of  the  area  to  be  printed  with  the  mouse.  The 
window  is  then  sized  by  selecting  and  holding  the  right  mouse  button  while  dragging 
the  mouse.  Releasing  the  mouse  button  after  sizing  the  camera  window  takes  a 
"picture"  of  the  contents  of  that  window  w'hich  is  sent,  in  Postscript  format,  to  a  file. 
The  file  is  automatically  transferred,  via  Ethernet,  to  our  VAX  computer  which  in 
turns  executes  a  print  command  to  a  Postscript  printer.  The  file  transfer  is  required  in 
order  to  access  the  laser  printer  that  is  linked  to  the  VAX  computer  system.  Figure 
4.27  depicts  a  laser  printed  image  of  the  screen.  Note  that  the  camera  routine 
automatically  scales  a  "picture"  that  is  too  large  to  print  on  the  standard  8.5  x  11  inch 
paper  used  in  laser  printers.  Once  the  camera  option  is  selected,  the  user  must  snap  a 
picture;  there  is  no  way  to  abort  or  exit  from  this  option.  The  camera  option  can  be 
exercised  any  time  during  simulator  execution. 

8.  Legend 

The  main  menu’s  legend  option  display’s  the  elevation  contour  map’s  legend 
in  the  upper-left  window.  The  legend  depicts  the  colors  representing  16  contour 
intervals  that  were  calculated  by  dividing  the  difference  of  the  maximum  and  minimum 
database  elevations  by  16. 

9.  Change  Color 

The  change  color  menu  option  allows  the  elevation  contour  map  and  legend  to 
toggle  between  two  color  ramps,  a  gray  ramp  and  a  brown  ramp.  Both  ramps  are 
created  during  program  initialization  by  using  the  w'indow  manager’s  multimap  mode. 
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Figure  4.27  Laser  Printed  Image  of  Screen 
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The  change  color  menu  option  simply  changes  the  color  map  out  from  under  both 
windows;  switching  from  gray  to  brown  and  brown  to  gray.  Changing  the  color  map 
out  from  under  the  drawing  avoids  redrawing  the  entire  scene  with  the  new  color 
ramp.  Therefore,  we  incur  no  drawing  time  cost. 

10.  Swap  Elevation/Photo 

The  double-buffered  contour  map  window  allows  the  black  and  white  aerial 
photo  of  the  entire  database  to  be  drawn  in  the  back  buffer.  Since  the  elevation 
contour  map  and  the  aerial  photo  only  need  to  be  drawn  once,  we  found  that  double 
buffering  enables  us  to  draw  each  in  a  separate  buffer;  the  swap  elevation! photo  menu 
option  permits  toggling  between  the  two  buffers  with  no  drawing  time  cost. 

11.  Termination 

Program  execution  is  terminated  with  the  exit  option  in  the  main  menu.  Upon 
termination,  all  windows  are  closed,  the  system’s  color  map  is  restored,  and  the 
system’s  gamma  ramp  is  reset. 
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V.  SYSTEM  EVALUATION 


A.  PERFORMANCE  MEASUREMENTS 
1.  Complexity/Speed 

The  HRDTM  simulator  operates  at  various  levels  of  drawing  complexity  which 
provides  an  excellent  means  for  evaluating  the  supporting  IRIS  graphics  hardware. 
Drawing  complexity,  in  this  instance,  refers  to  the  number  of  polygons  (triangles) 
drawn;  the  more  polygons  drawn,  the  more  complex  the  view.  This  complexity  varies 
with  missile  height  and  tilt  angle.  Essentially,  the  complexity  increases  as  both  the 
height  and  tilt  increase  because  more  and  more  terrain  comes  into  view;  therefore, 
more  terrain  must  be  drawn.  Note  that  this  is  not  always  true  because  of  the  display 
algorithm  that  is  used.  This  is  noticeable  in  the  performance  measurements  depicted 
in  Tables  5.1,  5.2,  5.3,  and  5.4.  These  measurements  were  taken  over  a  wide  range  of 
viewing  angles,  but  this  does  not  appear  to  have  effected  system  drawing 
performance  in  any  manner.  Our  measurements  indicate  that  system  drawing 
performance  is  in  the  neighborhood  of  36,000  to  41,000  Gouraud  shaded  triangles  per 
second. 


2.  Realism 

Judging  the  realism  of  the  images  generated  by  the  system  is  a  very  subjective 
process.  Our  evaluation  does  account  for  the  fact  that  we  have  personally  surveyed 
the  area  of  Fort  Hunter-Liggett,  California  that  comprises  our  database.  Having 
visited  and  photographed  the  area,  we  can  match  generated  terrain  images  with  black 
and  white  photos.  We  would  have  had  considerable  difficulty  doing  this  if  we  would 
not  have  surveyed  the  area  prior  to  our  system  evaluation.  This,  however,  only 
applies  to  photos  taken  at  ground  level.  Figures  5. 1  and  5.3  depict  35  mm  black  and 
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TABLE  5.1  HRDTM  PERFORMANCE  MEASUREMENTS  ON  IRIS  4D/70GT 


TILT  ANGLES  (DEGREES) 

1 

20 

45 

89 

HEIGHT  (METERS'! 

1 

1 

1 

1 

SECTORS  (METER  SI 

12 

12 

24 

72 

DRAW  (METERS) 
DISTANCE 

685 

685 

72 

2 

FRAMES  PER 

SECOND 

0.93  - 1.14 

0.89  - 1.14 

4.5  -  5.7 

20-32 

TRIANGLES  PER 
FRAME 

33  -  40,000 

33.5  -  40,400 

7  -  8,000 

1,300  -  1,600 

TRIANGLES  PER 
SECOND  (AVG) 

37,410 

37,073 

37,950 

36,800 

TABLE  5.2  HRDTM  PERFORMANCE  MEASUREMENTS  ON  IRIS  4D/70GT 


TILT  ANGLES  (DEGREES) 

1 

20 

15 

89 

HEIGHT  (METERS) 

100 

100 

100 

100 

SECTORS  (METERS) 

12 

12 

24 

72 

DRAW  (METERS) 
DISTANCE 

685 

685 

685 

217 

FRAMES  PER 

SECOND 

1.35  - 1.68 

1.38-1.65 

0.68  -  0.78 

0.90  -  0.97 

TRIANGLES  PER 
FRAME 

22.5  -  27,300 

22.6  -  26,800 

49.5  -  53,300 

41.8  -  44,200 

TRIANGLES  PER 
SECOND  (AVG) 

36,990 

37,137 

37,427 

40,546 
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TADLE  5.3  HRDTM  PERFORMANCE  MEASUREMENTS  ON  IRIS  4D/70GT 


TILT  ANGLES  (DEGREES) 

1 

20 

45 

89 

HEIGHT  (METERS) 

200 

200 

200 

200 

SECTORS  (METERS) 

12 

12 

24 

72 

DRAW  (METERS) 
DISTANCE 

685 

685 

685 

436 

FRAMES  PER 

SECOND 

1.33  - 1.67 

1.32-1.63 

0.68  -  0.76 

0.32 

TRIANGLES  PER 
FRAME 

22.8  -  27,800 

22.7  -  26,450 

48.5  -  53,600 

128.5-129,300 

TRIANGLES  PER 
SECOND  (AVG) 

37,525 

35,958 

36,654 

41,248 

TABLE  5.4  HRDTM  PERFORMANCE  MEASUREMENTS  ON  IRIS  4D/70GT 

TILT  ANGLES  (DEGREES) 

1 

20 

45 

89 

HEIGHT  (METERS) 

400 

400 

400 

400 

SECTORS  (METERS) 

12 

12 

24 

72 

DRAW  (METERS) 
DISTANCE 

685 

685 

685 

685 

FRAMES  PER 

SECOND 

1.36  -  1.67 

1.36-1.60 

0.7  -  0.79 

0.25 

TRIANGLES  PER 
FRAME 

22.4  -  26,500 

23  -  27,500 

47.6  -  52,700 

148.3-149,800 

TRIANGLES  PER 
SECOND  (AVG) 

36,724 

37,100 

37.247 

37,263 
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white  photos  of  selected  areas  of  Fort  Hunter-Liggett,  while  Figures  5.2  and  5.4 
depict  the  computer  generated  images  of  the  respective  areas. 

We  also  evaluated  the  quality  of  images  generated  when  the  missile’s 
viewing  position  increased  in  height  and  tilt  angle.  We  discovered  that  gray-scale 
shading  and  coloring  offers  extremely  little  vegetation  and  cultural  feature  information 
from  a  vantage  point  below  100  meters.  As  depicted  in  Figures  5.2  and  5.4,  trees, 
shrubs,  rocks,  and  other  features  all  appear  as  shaded  hills;  essentially,  blending  with 
the  terrain.  At  100  meters,  as  depicted  in  Figure  5.5,  trees  begin  to  come  into  focus 
and  roads  can  be  detected  at  a  tilt  angle  of  25  degrees.  Vegetation  and  other  terrain 
data  becomes  more  easily  discemable,  as  shown  in  Figure  5.6,  when  the  tilt  angle 
exceeds  55  degrees.  The  problem  with  exceeding  55  degrees  tilt,  however,  is  that  the 
three-dimensional  drawing  effect  is  lost.  At  tilt  angles  this  great,  the  display  appears 
as  a  two-dimensional  black  and  white  photo. 

The  quality  of  the  two-dimensional  black  and  white  display  is  outstanding. 
Figures  5.7  and  5.8  depict  examples.  We  discovered  the  resolution  so  good  that  we 
could  display  every  other  point  in  the  database  and  still  not  lose  any  discernible 
amount  of  information.  The  fast  pixel  access  and  display  functions  provided  in  the 
system’s  graphics  library  appear  to  display  the  images  almost  instantaneously. 

B.  SYSTEM  LIMITATIONS 

1.  Simulator  Limitations 

The  HRDTM  simulator  was  designed  and  implemented  quickly  in  order  to 
investigate  the  possibility  of  generating  realistic  images  of  terrain  from  processed 
aerial  photo  database".  Tt  c'*rved  this  purple  well,  but  the  rapid  prototype 
processing  imposed  some  restrictions  and  limitations  on  the  system. 

The  user  is  restricted  to  flying  his  FOGM  in  a  selected  operating  area  of  288 
meters  x  288  meters.  Ideally,  the  user  should  be  able  to  select  a  start  point  for  his 
missile  and  then  he  should  be  able  to  fly  throughout  the  entire  database. 
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I'iyurc  5.6  l  lii('e-I)imcnsioii;il  View  55 


I'ijiiire  5.7  Compiler  (ienoraled  Two-Dimensional  View 


Kijjnrc  5.8  Computer  Ccnerak'd  Two-Dimensional  View 


The  system  also  lacks  the  ability  to  output  the  missile’s  location  in  UTM  grid 
coordinates.  The  layout  of  the  database  does  not  contribute  to  the  development  of  a 
simple  position-location  algorithm;  therefore,  it  was  not  pursued. 

2.  Database  Anomalies 

The  first  anomaly  to  appear  in  the  terrain  display  during  a  system  run  is 
caused  from  terrain  elevation  database  inaccuracies.  Very  hilly  terrain  is  displayed  in 
areas  that  are  located  in  extremely  light  portions  of  the  aerial  photo.  Roads,  for  in¬ 
stance,  appear  as  though  they  are  covered  with  boulders.  Figure  5.9  depicts  such  an 
example.  In  our  estimate,  this  is  caused  from  the  database  processing  program’s  in¬ 
ability  to  highly  correlate  extremely  light  areas  on  stereo  pairs. 

The  shadow's  that  are  present  in  our  overhead  photos  create  a  second 
anomaly.  When  viewing  the  three-dimensional  perspective  views  from  certain  angles, 
it  appears  as  though  the  gray-scale  data  was  "shifted"  during  the  coloring  process.  In 
other  w'ords,  sides  of  trees  appear  very  lightly  colored  instead  of  dark.  This  is  not  the 
case,  however.  This  shift  appears  because  one  side  of  the  tree,  in  this  case,  was 
brightly  lighted  from  the  sun,  while  terrain  on  the  other  side  is  dark  from  the  tree’s 
shadow. 

The  other  anomaly  that  appears  in  the  terrain  display  is  also  caused  from 
inaccuracies  in  the  terrain  elevation  database.  A  "wall  of  terrain"  occurs  along  two 
edges  of  the  database.  Figure  5.10  depicts  an  example  of  this  problem.  Once  again, 
we  attribute  this  problem  to  the  processing  techniques  used  to  create  the  database. 
We  believe  that  this  was  caused  by  an  averaging  methodology  that  was  used  on  a 
group  of  pixels  (or  points)  while  scanning  an  aerial  photo.  When  the  scan  reached  the 
edge  of  the  photo,  the  processing  algorithm  appears  to  have  averaged  the  remainder 
of  its  scan  lines  with  the  last  piece  of  data  that  it  obtained.  As  a  result,  the  outer  two 
edges  of  the  database  consist  of  duplicated  data.  This  duplicate  elevation  data 
appears  as  a  wall  when  displayed. 
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Figure  5. V  1 );»{ :»l»;isv  Anomalies 


I'i^inc  5.10  Database  Anomalies 


VI.  SUMMARY 


A.  CONCLUSIONS 

This  study  originated  from  our  desire  to  generate  more  realistic  images  than  those 
currently  generated  by  three-dimensional  visual  simulators  such  as  the  Moving 
Platform  Simulator  [Ref.  2],  We  discovered  that  realism  was  greatly  enhanced  by 
increasing  the  resolution  of  the  terrain  elevation  database.  As  we  expected,  however, 
increasing  resolution  slows  the  simulator  drastically.  One  point  that  we  found 
interesting  was  that  0.3  meter  resolution  provided  us  no  more  noticeable  information 
than  0.6  meter  resolution.  Our  database  storage  requirements  can  be  cut  in  half  if  we 
use  a  0.6  meter  resolution  database,  and  we  will  not  sacrifice  much  information  loss. 
Another  important  result  of  our  study  is  that  we  discovered  that  texturing  the  terrain 
w’ith  corresponding  aerial  photo  reflectance  data  provides  almost  no  information  until 
we  view  the  terrain  from  almost  directly  overhead.  In  the  overhead  case,  however,  we 
lose  the  height  aspect  of  the  three-dimensional  drawing;  therefore,  we  are  better  off 
displaying  the  two-dimensional  aerial  photo,  a  much  faster  process. 

In  the  area  of  graphics  workstation  performance  evaluation,  we  can  conclude  that 
the  IRIS  4D/70GT  draws,  on  the  average,  37,000  Gouraud  shaded  triangles  per 
second.  The  HRDTM  simulator  generates,  in  its  worst  case,  an  overhead  view  of  a 
288  meter  x  288  meter  segment  of  terrain  requiring  approximately  150,000  Gouraud 
shaded  triangles.  Therefore,  the  HRDTM  simulator  is  capable  of  only  a  0.25  frames 
per  second  drawing  rate  during  a  worst-case  scenario.  Thus,  the  current  drawing  rate 
is  insufficient  to  drive  the  HRDTM  simulator  at  our  real-time  requirement  of  two  to 
three  frames  per  second. 
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B.  FUTURE  RESEARCH 


The  high-resolution  database  does,  however,  offer  an  excellent  source  for  other 
research.  One  such  use  would  involve  integrating  only  the  terrain  elevation  portion  of 
the  HRDTM  database  directly  into  MPS.  Since  standard  Defense  Mapping  Agency 
(DMA)  databases  normally  provide  only  100  meter  resolution  and  the  special  Fort 
Hunter-Liggett  database  provides  only  12.5  meter  resolution,  the  high-resolution 
terrain  elevation  data  file  may  provide  an  excellent  alternative  database  for  improving 
Moving  Platform  Simulator  accuracy. 

Since  coloring  and  shading  the  terrain  with  its  corresponding  aerial  photo  gray¬ 
scale  data  provided  little  cultural  feature  and  vegetation  information,  there  is  still  a 
requirement  to  display  this  information.  Therefore  other  research  could  involve  using 
both  the  elevation  and  reflectance  data  files  along  with  artificial  intelligence 
techniques  to  determine  cultural  features.  Once  these  features  are  identified,  one  may 
then  generate  synthetic  cultural  features  in  the  display. 

Another  area  of  possible  research  is  the  management  of  large  terrain  databases. 
Terrain  database  design,  file  management,  and  storage  will  play  a  crucial  role  in  future 
systems  that  will  have  to  access  and  display  huge  amounts  of  information.  Optimizing 
database  design  for  ease  of  file  access  and  storage  offers  an  excellent  opportunity  for 
research.  CDEC  has  recently  obtained  an  80  square  kilometer  high-resolution  terrain 
elevation  and  gray-scale  database  of  the  entire  Fort  Hunter-Liggett  area.  This 
database  can  provide  a  starting  point  for  such  database  research. 

Real-time  generation  of  realistic  two  and  three-dimensional  terrain  displays 
remains  an  exciting  area  of  research.  Research  is  limited  only  by  the  resolution  of 
digital  terrain  elevation  databases,  central  processor  memory,  and  faster  computer 
graphics  hardware.  Even  now,  however,  great  strides  are  being  made  to  overcome 
each  of  these  limitations.  Database  resolution  is  better  and  more  available  than  ever 
before.  Faster  and  more  capable  graphics  hardware  is  also  becoming  more  available 
and  affordable.  As  each  of  these  restrictions  is  overcome,  greater  and  greater 


59 


achievements  will  be  realized.  In  light  of  these  advances  and  continuing  research,  we 
feel  that  the  work  completed  in  this  thesis  will  provide  an  excellent  stepping  stone  for 
future  research. 
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